Device Transfer of a Server Stored Data Item Based on Item ID and Determined Nature of Intended Destination

ABSTRACT

There is provided a method and system for communicating data items about a communication network. An original data item for communicating to a destination device is cached to a network data store in association with unique ID (UID) generated to identify the original data item. The UID is then sent as a proxy for the original data item to the destination device. The original data item may be processed (e.g. in response to a type of the destination device) to create a processed data item and the processed data item sent in place of the original data item. The processed data item may also be cached in association with the UID, for example, for reuse to eliminate duplicate processing. The destination device is adapted to return the UID when further communicating the original data item thereby to reduce communication of the original data item about the communication network.

FIELD

The present application relates to electronic data communications, inparticular, communicating data items from one data communications deviceto another via an intermediate server.

BACKGROUND

Electronic data communications between users, such as electronic mail(email), instant messaging (IM), short message service (SMS) and thelike is increasingly popular. Often, users wish to communicate dataitems (i.e. files) to one another including images, video or audioclips, text or word processing documents, etc. However, some userdevices such as handheld electronic devices (e.g. mobile telephones,personal digital assistants (PDAs), MP3 players, etc.) and particularlythose communicating via wireless communication networks are moresensitive to resource limitations.

When developing software for such handheld devices, there are a numberof limitations that may be taken into consideration in order to makehandheld device operations fast and efficient. Limited memory resources,communication bandwidth, and battery power consumption is only ashortlist of issues handheld software developers have to think about.

One of the solutions to reducing resource consumption is to reduce theamount of data to be passed to and/or stored by the handheld device. Forexample, image files may undergo processing or conversion with a view tocompressing the size of the image data. Often such treatment reduces aquality of the image. Also it demands image conversion every time thesame image is sent/forwarded to a handheld device providing an extraload on the server executing the file processing. Another problem ariseswhen an image that was specifically converted for a handheld device getsforwarded to a recipient (by e-mail, for example), who uses a desktopcommunication device: the reduced quality image arrives rather than theoriginal image, although the recipient is capable of viewing a betterquality image.

A solution that addresses one or more of these issues is thereforedesired.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the subject matter may be readily understood, embodimentsare illustrated by way of examples in the accompanying drawings, inwhich:

FIG. 1 is a block diagram which illustrates pertinent components of afile processing system and handheld devices adapted in accordance withan embodiment and an example message flow; and

FIG. 2 is a flowchart of operations, in accordance with an embodiment,to communicate a message including a file;

FIG. 3 is a flowchart of operations, in accordance with an embodiment,to communicate a message including a unique ID referencing a file;

FIG. 4 is a flowchart of operations, in accordance with an embodiment,to process a file for a destination device; and

FIG. 5 is an example of a handheld device adapted in accordance with anembodiment.

DETAILED DESCRIPTION

There is provided a method and system (among other aspects) forcommunicating data items about a communication network. An original dataitem for communicating to a destination device is cached to a networkdata store in association with unique ID (UID) generated to identify theoriginal data item. The UID is then sent as a proxy for the originaldata item to the destination device. The original data item may beprocessed (e.g. in response to a type of the destination device) tocreate a processed data item and the processed data item sent in placeof the original data item. The processed data item may also be cached inassociation with the UID, for example, for reuse to eliminate duplicateprocessing. The destination device is adapted to return the UID whenfurther communicating the original data item thereby to reducecommunication of the original data item about the communication network.

FIG. 1 illustrates pertinent components of an electronic datacommunication system 100 for communicating data items such as image,video and/or audio files (e.g. 120, 122 and 124) between users ofvarious electronic data communication devices (102, 104, 106 and 108)having varying processing, storing, displaying and/or communicatingcapabilities as described below. In the illustrated embodiment, arepresentative file processing system 110 is interposed between the userdevices 102, 104, 106 and 108 for processing the data communications anddata files.

Persons of skill in the art will appreciate that various wireless andwired network infrastructure is not shown. For example, devices 102 and104 in the example of FIG. 1 comprise “desktop” data communicationdevices such as PC's, laptops, workstations, or other similar devicescharacterized by their relatively powerful processors, plentiful storageand large screen displays when compared to handheld devices 106 and 108.Desktop devices 102 (desktop_1) and 104 (desktop_2) may be configured tocommunicate with file processing system 110 via high speed networks suchas wired networks (LANs, WANs, public and/or private) that may includeshort range wireless networks (e.g. Wi-Fi, etc.). Devices 102 and 104may be coupled via emerging high speed wireless networks such assatellite, microwave or other technology providing high-bandwidth atrelatively comparable costs to conventional wired networks.

In contrast, handheld devices 106 and 108 comprise devices such ascellular telephones, PDAs, etc. characterized by one or more resourcelimitations or costs related to processor speed, memory/storage size orlatency, display size and network communication speed or expense (e.g.charges per unit transmitted). In the present embodiment, handhelddevices 106 (handheld_1) and 108 (handheld_2) typically communicate withfile processing system 110 via a data network which comprises one ormore wireless communication networks (GSM/GPRS, CDMA, 3G, etc.).

File processing system 110 comprises a computer server coupled to a datastore 112 configured to receive data communications (messages) from asource for delivery to one or more destinations. File processing system110 may be a component in the communication network that relays networktraffic and is capable of modifying packets based on application logic.The data communications may include one or more data items or files.File processing system 110 may process the files to generate processeddata items in response to the destination, such as to reduce file sizeor convert to a compatible file type, etc. to meet the needs of thedestination or reduce bandwidth etc. as described. Additionally, fileprocessing system 110 may store the file (or any file location if thefile is available to the file processing system via a network) andassign the file a unique ID (UID), which UID is sent to the destinationwith the processed data item (file) as applicable. Destinations notrequiring processing of a file need not receive the UID or a processedfile.

File processing system 110 comprises one or more fileprocessors/converters 150, a UID generator 152, a destination determiner154 and send/receive mechanisms (e.g. queues) 156. File processingsystem 110 is communicatively coupled to a cache 112 (e.g. a data store)for storing files (or file locations) from messages (e.g. LF 120) andUIDs (e.g. UID_1 126 and UID_2 128) and, optionally, processed files(e.g. SF_1 122 and SF_2 124). File processing system 110 comprises acache lookup and store module 160 for accessing cache data and a cachemaintenance module 162 for maintaining cache data, such as deletingstored files and/or UIDs in accordance with a cache scheme. Fileprocessing systems further comprises instructions and data implementingoperations for file processing, using the file processors/converters150, UID generator 152, destination determiner 154, send/receivemechanisms 156 and cache modules 60 and 162 described by way of examplesfurther below.

Destination devices receiving the forwarded message with a UID inassociation with a processed file (e.g. handheld_1, 106 and handheld_2,108) may be adapted to comprise a UID handler 130 and 132 for handlingthe UIDs as described further herein below.

FIG. 1 further illustrates an example message flow among the users ofvarious electronic data communication devices (102, 104, 106 and 108).In the example, user of device 102 sends a message Msg_(—)1 including alarge file LF 120 to two destinations, namely the respective users ofhandheld_1 106 and handheld_2 108. Msg_(—)1 is routed via fileprocessing system 110. File processing system 110 receives the messagevia send/receive mechanism 156 and analyzes Msg_(—)1 to determine theprocessing requirements for each of the destinations (106 and 108) usingthe destination determiner 154. A cache lookup (160) may be performed tosee if LF was previously processed and cached with a processed filerequired for a destination.

If LF 120 was previously stored with a processed file required by thedestination, the converted file may be returned from the cache to reduceprocessing by file processing system 110. In this example, LF 120 hasnot been stored before its receipt with Msg 1.

For handheld_1 106, an appropriate file processor 150 creates SF_1 122in response to LF. UID generator 152 generates a first UID 126 for LF120. LF 120 and optionally SF_1 122 are stored to cache 112 via cachelookup/store 160. File processing system 110 routes a message, Msg 2, tohandheld_1 106 comprising the message of Msg 1 and SF_1 122 and UID_1126.

File processing system 110 follows similar steps for the remainingdestination, namely handheld_2 108. SF_2 124 is generated in response tothe requirements of handheld_2 108. Persons of skill in the art willunderstand that if the handhelds are of the same type (i.e. have thesame capabilities or requirements for file LF) then SF_1 may be usedrather than generating a second file SF_2. A second UID, UID_2 128, isgenerated for LF and it and optionally SF_2 are stored to cache 112. AsLF 120 is already stored, it need not be stored twice. A single commonUID may be used for LF rather than one per message. File processingsystem 110 generates Msg_(—)3 for handheld_2 108 including SF_2 124 andUID_2 128 and communicates it via send/receive mechanisms 156.

In this example, the user of handheld_2 108 desires to send LF to a userof desktop_2 (e.g. by forwarding Msg 3 or by other means such asdefining a new message and including file LF). The user of handheld_2may consider SF_2 124 to be LF 120 transparently. Handheld_2 and UIDhandler 132 cooperate to define a message, Msg 4, including UID_2 as aproxy for LF 120 to send via file processing system 110 for desktop_2104. Sending only UID_2 saves network bandwidth and processing resourceconsumption by various components in the network.

File processing system 110 receives Msg 4 and looks in cache 112 for LF120 using UID_2. Destination determiner 154 determines no processing isrequired for desktop_2 104. File processing system 110 defines amessage, Msg 5 from Msg 4 and includes LF 120 from the cache, sending itvia mechanism 156.

File processing system cache 112 resources are limited and there is alimit to the files that can be cached. Cache 112 can be maintained viacache maintenance module 162. Cache 112 may be cleared based on dateinformation, or last access date, or on the frequency of the file beingforwarded, or any other low memory management rule set. Optionally auser may be assigned a specific amount cache storage space and filesstored to the cache may be stored in association with user information.Cache maintenance schemes may be responsive to such user assigned spacelimits as well.

FIG. 2 is a flowchart showing example operations 200 to communicate amessage received with a file.

At step 204, the message is received including a file, File_In. Themessage also includes at least one destination. In accordance with thepresent embodiment, steps 206-220 define a loop for operations that areperformed, as applicable, for each of the destinations. Operations 200end following a branch from step 206 once all destinations are handled.At step 208, the type of destination D_Type is determined. Though notillustrated, a table or other lookup using the destination address, forexample, may be used to determine a destination type.

Various levels of granularity may be implemented using destinationtypes. At a very course level, there are two D_Types, one requiringprocessing of the file File_In and one not requiring processing. In thiscase, only one type of processing may be performed. Finer granularitymay be useful to determine different processing. In this way, allhandhelds need not be treated equally. For example, assume for aparticular file type (e.g. PDF from Adobe®) there are three D_Types:desktops (or unknown destinations) may define one type requiring noprocessing; a first group of handhelds with appropriate viewers defineanother type requiring processing and a second group of handhelds withdifferent viewers define a further type requiring a differentprocessing.

At step 210, a determination is made whether any processing (i.e. aconversion such as compressing, flattening or changing from one filetype to another) is required for the D_Type. If not, via step 212, amessage is defined and sent to the destination including the filereceived, File_In and operations loop to step 206.

If processing/converting is indicated at step 210 then at step 214File_in is processed in response to the D-Type to provide a File_Out. Asdiscussed below, if File_In was previously processed for the D_Type andthe processed file stored to the cache, File_Out may be retrieved toavoid repeating the processing. A UID is generated (step 216). At step218, File_In and the UID are stored to the cache. Optionally and asshown, the D_Type and File_Out are also stored in association with theUID so that repetitious file processing may be reduced. At step 220, amessage is defined for sending to the destination, including the UID andFile_Out. Operations 200 loop to step 206 for any further destinations.

FIG. 3 is a flowchart of operations 300, in accordance with anembodiment, to communicate a message including a unique ID referencing afile. Such messages are typically received from handheld devices but maybe for communicating to other handhelds or desktops, etc.

At step 304, a message is received with a UID for communicating to atleast one destination. At step 305, a lookup of the cache is performedto find the original file, File_In, associated with the UID. Operations306-320 define a loop for execution, as applicable, for eachdestination. In the present embodiment, operations 306-320 are the sameas operations 206-220. Accordingly, File_In is forwarded to thedestination or processed, as necessary for sending with a UID to thedestination. Though not illustrated, if at step 305 the lookup using UIDfails to return an original file (e.g. LF 120) an error may be returnedto the source of the message (e.g. handheld_1 106). The source devicemay be configured (also not shown) to resend the message with orotherwise provide the file (e.g. SF_1, as applicable) from a localstore.

FIG. 4 is a flowchart of operations 400, in accordance with anembodiment, to process a file for a destination device. At step 402, acache lookup determines and returns the required processed file(File_Out) for the destination type D_Type, if available. If File_Out isavailable, operations 400 branch at step 404 to return File_Outeliminating a repeated processing of File_In. If File_Out is notavailable, via branch at step 404 to step 406, in response to the D_Typestep 406, particular processing (e.g. 408, 410 . . . 412) may beperformed to generate File_Out before operations 400 end.

In certain situations, a destination device may not be able to process aparticular file type for a received file or it may be otherwisedesirable to not send the file or even a processed file to thedestination device (e.g. because it is too large). In situations wherethe server (file processing system 110) knows the destination device isnot capable of handling a specific file type, it may be advantageous tosend a UID along with a file type to the destination device, evenwithout the file. The destination device may be configured to determinehow to handle the information (e.g. display a stub icon in its place).The user of the destination device can forward the original file (i.e.UID) to another destination device that can process the file if desired.Thus, operations discussed above may be adapted by a person of ordinaryskill in the art to send a UID even when the device cannot handle thefile type.

Accordingly, the solution described decreases the amount of datatransferred over wireless networks, especially when communicating filesfrom the handheld device. The solution also seeks to address the issueof multiple conversions for the same file. Original files and processedfiles may be server cached. The solution also seeks to provideappropriate file quality for those devices that are capable to use “fullsize” files as well as those that require or otherwise desire to uselesser files.

As the UID is server generated and stored by the server and device,there is no limit as to which file can be tagged with a UID and sharedby means of UID-based file transfer.

FIG. 5 is a detailed block diagram of a preferred handheld device 502adapted in accordance with an embodiment that may be used as handheld_1106 for example. Handheld device 502 is preferably a two-waycommunication device having at least voice and advanced datacommunication capabilities, including the capability to communicate withother computer systems. Depending on the functionality provided byhandheld device 502, it may be referred to as a data messaging device, atwo-way pager, a cellular telephone with data messaging capabilities, awireless Internet appliance, or a data communication device (with orwithout telephony capabilities). Handheld device 502 may communicatewith any one of a plurality of base station transceiver systems (notshown) within its geographic coverage area.

Handheld device 502 will normally incorporate a communication subsystem511, which includes a receiver 512, a transmitter 514, and associatedcomponents, such as one or more (preferably embedded or internal)antenna elements 516 and 518, local oscillators (LOs) 513, and aprocessing module such as a digital signal processor (DSP) 520. As willbe apparent to those skilled in field of communications, particulardesign of communication subsystem 511 depends on the communicationnetwork in which handheld device 502 is intended to operate.

Handheld device 502 may send and receive communication signals over thenetwork after required network registration or activation procedureshave been completed. Signals received by antenna 516 through the networkare input to receiver 512, which may perform such common receiverfunctions as signal amplification, frequency down conversion, filtering,channel selection, and like, and in example shown in FIG. 5,analog-to-digital (A/D) conversion. A/D conversion of a received signalallows more complex communication functions such as demodulation anddecoding to be performed in DSP 520. In a similar manner, signals to betransmitted are processed, including modulation and encoding, forexample, by DSP 520. These DSP-processed signals are input totransmitter 514 for digital-to-analog (D/A) conversion, frequency upconversion, filtering, amplification and transmission over communicationnetwork via antenna 518. DSP 520 not only processes communicationsignals, but also provides for receiver and transmitter control. Forexample, the gains applied to communication signals in receiver 512 andtransmitter 514 may be adaptively controlled through automatic gaincontrol algorithms implemented in DSP 520.

Network access is associated with a subscriber or user of handhelddevice 502, and therefore handheld device 502 comprises a memory module562, such as a Subscriber Identity Module or “SIM” card or a RemovableUser Identity Module (R-UIM), to be inserted in or connected to aninterface 564 in order to operate in the network. Alternatively, memorymodule 562 may be a non-volatile memory that is programmed withconfiguration data by a service provider so that mobile station 502 mayoperate in the network. Since handheld device 502 is a mobilebattery-powered device, it also includes a battery interface 554 forreceiving one or more rechargeable batteries 556. Such a battery 556provides electrical power to most if not all electrical circuitry inhandheld device 502, and battery interface 254 provides for a mechanicaland electrical connection for it. The battery interface 554 is coupledto a regulator (not shown in FIG. 5) that provides power V+ to all ofthe circuitry.

Handheld device 502 includes a microprocessor 538 that controls overalloperation of mobile station 502. Communication functions, including atleast data and voice communications, are performed through communicationsubsystem 511. Microprocessor 538 also interacts with additional devicesubsystems such as a display 522, a flash memory 524, a random accessmemory (RAM) 526, auxiliary input/output (I/O) subsystems 528, a serialport 530, a keyboard 532, a speaker 534, a microphone 536, a short-rangecommunications subsystem 540, and any other device subsystems generallydesignated at 542. Some of the subsystems shown in FIG. 5 performcommunication-related functions, whereas other subsystems may provide“resident” or on-device functions. Notably, some subsystems, such askeyboard 532 and display 522, for example, may be used for bothcommunication-related functions, such as entering a text message fortransmission over a communication network, and device-resident functionssuch as a calculator or task list. Operating system software used bymicroprocessor 538 is preferably stored in a persistent store such asflash memory 524, which may alternatively be a read-only memory (ROM) orsimilar storage element (not shown). Those skilled in the art willappreciate that the operating system, specific device applications, orparts thereof, may be temporarily loaded into a volatile store such asRAM 526.

Microprocessor 538, in addition to its operating system functions,preferably enables execution of software applications on handheld device502. A predetermined set of applications that control basic deviceoperations, including at least data and voice communicationapplications, will normally be installed on handheld device 502 duringits manufacture. A preferred application that may be loaded ontohandheld device 502 may be a personal information manager (PIM)application having the ability to organize and manage data itemsrelating to user such as, but not limited to, e-mail, calendar events,voice mails, appointments, and task items. Naturally, one or more memorystores are available on handheld device 502 and SIM 562 to facilitatestorage of PIM data items and other information.

The PIM application preferably has the ability to send and receive dataitems via the wireless network. In a preferred embodiment, PIM dataitems are seamlessly integrated, synchronized, and updated via thewireless network, with the mobile station user's corresponding dataitems stored and/or associated with a host computer system therebycreating a mirrored host computer on handheld device 502 with respect tosuch items. This is especially advantageous where the host computersystem is the mobile station user's office or enterprise computersystem. Additional applications may also be loaded onto handheld device502 through network, an auxiliary I/O subsystem 528, serial port 530,short-range communications subsystem 540, or any other suitablesubsystem 542, and installed by a user in RAM 526 or preferably anon-volatile store (not shown) for execution by microprocessor 538. Suchflexibility in application installation increases the functionality ofhandheld device 502 and may provide enhanced on-device functions,communication-related functions, or both. For example, securecommunication applications may enable electronic commerce functions andother such financial transactions to be performed using handheld device502.

In a data communication mode, a received signal such as a text message,an e-mail message, or web page download will be processed bycommunication subsystem 511 and input to microprocessor 538.Microprocessor 238 will preferably further process the signal for outputto display 522 or alternatively to auxiliary I/O device 528. A user ofhandheld device 502 may also compose data items, such as e-mailmessages, for example, using keyboard 532 in conjunction with display522 and possibly auxiliary I/O device 528. Keyboard 532 is preferably acomplete alphanumeric keyboard and/or telephone-type keypad. Thesecomposed items may be transmitted over a communication network throughcommunication subsystem 511.

For voice communications, the overall operation of handheld device 502is substantially similar, except that the received signals would beoutput to speaker 254 and signals for transmission would be generated bymicrophone 536. Alternative voice or audio I/O subsystems, such as avoice message recording subsystem, may also be implemented. Althoughvoice or audio signal output is preferably accomplished primarilythrough speaker 534, display 522 may also be used to provide anindication of the identity of a calling party, duration of a voice call,or other voice call related information, as some examples.

Serial port 530 in FIG. 5 is normally implemented in a personal digitalassistant (PDA)-type communication device for which synchronization witha user's desktop computer is a desirable, albeit optional, component.Serial port 530 enables a user to set preferences through an externaldevice or software application and extends the capabilities of handhelddevice 502 by providing for information or software downloads tohandheld device 502 other than through a wireless communication network.The alternate download path may, for example, be used to load anencryption key onto handheld device 502 through a direct and thusreliable and trusted connection to thereby provide secure devicecommunication.

Short-range communications subsystem 540 is an additional optionalcomponent that provides for communication between handheld device 502and different systems or devices, which need not necessarily be similardevices. For example, subsystem 540 may include an infrared device andassociated circuits and components, or a Bluetooth™ communication moduleto provide for communication with similarly enabled systems and devices.Bluetooth™ is a registered trademark of Bluetooth SIG, Inc.

Handheld devices 502 may be adapted such as via software (instructionsand data) to handle UIDs as described above. A UID received with amessage may be persisted to the device (e.g. in association with themessage). When the message is forwarded to a user, any receivedprocessed file may be omitted from the forwarded message and the UIDsent as a proxy for the original file. For example, if the messagereceived and to be forwarded is an email, the UID may define as a headerfield of the email, a portion of the body or as an attachment inaccordance with email protocols. An email application on handheld device502 may be adapted to remove the received processed file when forwardingthe message.

Although embodiments have been described herein, it will be understoodby those skilled in the art that variations may be made thereto withoutdeparting from their spirit or the scope of the appended claims.

1. A method of receiving data items, from a file processing system in acommunication network on behalf of a first device, at a second device,the second device being coupled to the communication network via thefile processing system, the file processing system being interposedbetween the first device and the second device, the method comprising:the second device enabling the file processing system to determinecapabilities of the second device for handling file types for the dataitems; when the second device is not capable of handling a first filetype for an original data item intercepted by the file processing systemduring an original communication sent by an originating device to thefirst device, the second device receiving from the file processingsystem a unique ID associated with the original data item, and anindication of the first file type without the original data item; andwhen the second device is capable of handling a second file type for theoriginal data item, the second device receiving from the file processingsystem on behalf of the first device in completing a subsequentcommunication either the original data item or a processed data itemaccording to the capabilities of the second device; the file processingsystem having associated the unique ID with the original data item,cached the original data item and the unique ID, sent the unique ID andthe original data item to the first device in completing the originalcommunication, received the unique ID from the first device in thesubsequent communication, and having determined whether the data item isassociated with the first file type or the second file type indetermining whether the second device is capable of handling theoriginal data item.
 2. The method of claim 1, further comprisingforwarding the unique ID to another device that can process the originaldata item when the second device is not capable of handling the firstfile type.
 3. The method of claim 1, further comprising processing theoriginal data item at the second device when the second device iscapable of handling the second file type.
 4. The method of claim 1,further comprising sending another data item to a new destination devicevia the file processing system to have the file processing systemgenerate a new unique ID for the other data item to be provided to thenew destination device for further sending the other data item about thecommunication network.
 5. The method of claim 1, wherein the seconddevice is a handheld device.
 6. The method of claim 1, wherein thesecond device is a desktop computer.
 7. A non-transitory computerreadable medium comprising computer executable instructions forreceiving data items, from a file processing system in a communicationnetwork on behalf of a first device, at a second device, the seconddevice being coupled to the communication network via the fileprocessing system, the file processing system being interposed betweenthe first device and the second device, the computer executableinstructions comprising instructions for: the second device enabling thefile processing system to determine capabilities of the second devicefor handling file types for the data items; when the second device isnot capable of handling a first file type for an original data itemintercepted by the file processing system during an originalcommunication sent by an originating device to the first device, thesecond device receiving from the file processing system a unique ID andan indication of the first file type without the original data item; andwhen the second device is capable of handling a second file type for theoriginal data item, the second device receiving from the file processingsystem on behalf of the first device in completing a subsequentcommunication either the original data item or a processed data itemaccording to the capabilities of the second device; the file processingsystem having associated the unique ID with the original data item,cached the original data item and the unique ID, sent the unique ID andthe original data item to the first device in completing the originalcommunication, received the unique ID from the first device in thesubsequent communication, and having determined whether the data item isassociated with the first file type or the second file type indetermining whether the second device is capable of handling theoriginal data item.
 8. The non-transitory computer readable medium ofclaim 7, further comprising instructions for forwarding the unique ID toanother device that can process the original data item when the seconddevice is not capable of handling the first file type.
 9. Thenon-transitory computer readable medium of claim 7, further comprisinginstructions for processing the original data item at the second devicewhen the second device is capable of handling the second file type. 10.The non-transitory computer readable medium of claim 7, furthercomprising instructions for sending another data item to a newdestination device via the file processing system to have the fileprocessing system generate a new unique ID for the other data item to beprovided to the new destination device for further sending the otherdata item about the communication network.
 11. The non-transitorycomputer readable medium of claim 7, wherein the second device is ahandheld device.
 12. The non-transitory computer readable medium ofclaim 7, wherein the second device is a desktop computer.
 13. A seconddevice configured for receiving data items, from a file processingsystem in a communication network on behalf of a first device, thesecond device being coupled to the communication network via the fileprocessing system, the file processing system being interposed betweenthe first device and the second device, the second device comprising acommunications subsystem for communicating data items, a processor, anda memory storing computer executable instructions and data to configurethe second device to: enable the file processing system to determinecapabilities of the second device for handling file types for the dataitems; when the second device is not capable of handling a first filetype for an original data item intercepted by the file processing systemduring an original communication sent by an originating device to thefirst device, receive from the file processing system a unique ID and anindication of the first file type without the original data item; andwhen the second device is capable of handling a second file type for theoriginal data item, receive from the file processing system on behalf ofthe first device in completing a subsequent communication either theoriginal data item or a processed data item according to thecapabilities of the second device; the file processing system havingassociated the unique ID with the original data item, cached theoriginal data item and the unique ID, sent the unique ID and theoriginal data item to the first device in completing the originalcommunication, received the unique ID from the first device in thesubsequent communication, and having determined whether the data item isassociated with the first file type or the second file type indetermining whether the second device is capable of handling theoriginal data item.
 14. The second device of claim 13, furtherconfigured to forward the unique ID to another device that can processthe original data item when the second device is not capable of handlingthe first file type.
 15. The second device of claim 13, furtherconfigured to process the original data item at the second device whenthe second device is capable of handling the second file type.
 16. Thesecond device of claim 13, further configured to send another data itemto a new destination device via the file processing system to have thefile processing system generate a new unique ID for the other data itemto be provided to the new destination device for further sending theother data item about the communication network.
 17. The second deviceof claim 13, wherein the second device is a handheld device.
 18. Thesecond device of claim 13, wherein the second device is a desktopcomputer